[fix] Resume a gated turn under the config it was running (10/12) - #5689

Grounded in two live experiments on the EE dev stack:

- A dirty-config run's session_interactions row carries only
  workflow + workflow_variant references (no workflow_revision), so a
  references-only resume hydrates the variant HEAD, not the draft the
  turn ran under. A committed run's revision reference is pinned and is
  therefore already immune to later commits.
- A warm approval resume keeps the sandbox's acquire-time model and
  secrets while re-reading the permission map from the incoming
  (hydrated, committed) request -- a split brain where the approval UI
  enforced one policy and the resumed turn enforces another. Cold replay
  runs the committed config end to end against a draft transcript.

Recommends stamping the effective parameters on the interaction row at
gate creation (SDK emits, runner echoes, API replays inline), which needs
no migration, with a detect-and-defer fallback for pre-change rows.

A HITL gate answered from a client that cannot reproduce the turn's config (mobile, the
M2 dispatcher) resumes references-only, so the SDK hydrates the referenced variant's HEAD
revision instead of what the gated turn was running - wrong model, wrong instructions, and
wrong tool permissions on a dirty run.

The SDK is the only component holding the post-hydration config, so it emits it: the
handler carries its resolved data.parameters onto SessionConfig, and request_to_wire puts
it on the wire as the opaque effectiveParameters. Emitted only for a session run (nothing
else can park a gate), so an ad-hoc run's payload stays byte-identical to the golden
contract. Redacted (an MCP connection's static headers are the one place the schema
permits a raw credential; the vault-key refs survive) and capped at 64 KB, dropped whole
with a log line rather than truncated into invalid JSON.

The runner echoes the blob onto the interaction row; the answering client replays it as
data.parameters, which suppresses hydration and reproduces the turn.

The runner writes the durable row at the exact moment a gate parks, so it is where the
turn's config has to be recorded - but it had no access to it (there was no parameters
field on the /run wire at all). The SDK now stamps effectiveParameters; this echoes it
verbatim into the row's data.parameters, alongside data.request and data.references.

Opaque by design: the runner never reads inside the blob and derives no behavior from it.
It is deliberately NOT in configFingerprint - that hash decides warm resume vs cold replay,
and the blob is a projection of fields already hashed, so including it would let a cosmetic
serialization change evict every warm session. A turn with no stamped config omits the KEY
(not null, not {}): a legacy row keeps its exact shape, and an empty inline config would
still suppress hydration server-side and resume a toolless agent.

Two links in the same chain. The DTO: SessionInteractionData is a closed pydantic model
with the default extra="ignore", and the postgres mapping round-trips through it on write
and on read even though data is a schemaless json column - so the runner's new
data.parameters was being dropped twice with no error anywhere. Declaring the field is the
whole fix; no migration.

The dispatcher: when the row carries a config, send it inline on the resume. The SDK
resolver decides hydration purely from what the caller sent, so inline parameters suppress
it and the run continues under the config the gate was raised against instead of the
referenced variant's HEAD revision. References still ride along as attribution. A row
written before the runner stamped configs has none and produces the byte-identical
references-only body this dispatcher has always sent.

Records what landed on the backend lanes of the effective-turn-config plan and notes in the
approvals round-trip that a pre-change row (or one over the stamp cap) is still answerable,
degrading to reference hydration.

The lite resume answered a HITL gate with a references-only body, so the SDK
hydrated the referenced variant's HEAD revision. For a dirty run that is a
different model and — the security-relevant half — a different tool-permission
map than the gate was approved under.

The runner now stamps the turn's post-hydration config onto the interaction row
as data.parameters. Read it off the same row the references come from and send
it inline, which suppresses hydration and reproduces the turn exactly.

Emit the key ONLY when the stamped config is a non-empty object: an empty {}
also suppresses hydration and would run an unconfigured agent. Rows without it
(legacy, over-cap, pre-stamping runner) keep today's references-only path.

Declare parameters on the interaction zod schema too — objects strip unknown
keys by default, so an undeclared field would be silently dropped and the fix
would no-op with everything green.

The phone built its own /invoke resume from a stamped records replay. That lands as a
NEW turn (the keepalive trips approval-mismatch (history) -> evict + cold), so the parked
gate is never matched and the interaction row stays pending — the desktop keeps showing
"Approval needed to continue" even after the tool ran.

Call POST /sessions/interactions/{id}/respond instead: the backend CAS-flips the row to
responded and the interactions worker rebuilds the history server-side and replays the
gate's stamped effective config, so the resume lands warm. Approve-all fans out one
respond per pending gate; a 409 (already answered) settles to idle instead of erroring.

respondInteraction now throws instead of swallowing the failure — a mutation's caller has
to tell a real failure from an already-answered gate (isInteractionConflict).

Drops the mobile-only invoke plumbing: approvalStamp.ts and the invoke bearer header.